-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not bind the Management port into the generated Service resource #33694
Conversation
Related to quarkusio#33307, task 4. Yet if users set the target-port to "management", this port won't be unbound.
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
|
✔️ The latest workflow run for the pull request has completed successfully. It should be safe to merge provided you have a look at the other checks in the summary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea. We have a sane default, and the user can override it.
Is it something that should be backported to 3.1? |
@gsmet it can wait 3.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
After quarkusio#33696 being merged, the port https is no longer bound by default. The problem is that I merged quarkusio#33694 without rebasing and these two tests needed to be updated.
After quarkusio#33696 being merged, the port https is no longer bound by default. The problem is that I merged quarkusio#33694 without rebasing and these two tests needed to be updated.
Related to #33307, task 4.
Yet if users set the "target-port" to "management", this port won't be unbound. I wanted to open this possibility to users that for some reason do want to expose the management port, so let me know what you think about this @iocanel @cescoffier